home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Human.Int.Notes / HIN.003 < prev    next >
Encoding:
Text File  |  1990-02-21  |  3.5 KB  |  66 lines  |  [TEXT/pdos]
  1. Human Interface Notes
  2. _____________________________________________________________________________
  3.  
  4. Note #3:    Dueling Metaphors:  the Desktop & HyperCard               
  5.     
  6.             Written by:  Tom Erickson                            January 1990
  7.             (Supersedes Human Interface Update #14)
  8. _____________________________________________________________________________
  9.  
  10. Discussion of the differences between the metaphors of the 
  11. Desktop and HyperCard.
  12. _____________________________________________________________________________
  13.  
  14. Metaphors help users form a coherent model of an application's human 
  15. interface.  In an interface with a well-chosen metaphor like the Desktop, 
  16. users find it easy to predict the results of an action or to figure out 
  17. which action produces a desired result.
  18.  
  19. While a single, clear metaphor aids human-computer communication, 
  20. mixing metaphors may cause significant problems.  Even  two metaphors 
  21. which work well separately may interfere with one another when they are 
  22. used within the same human interface.
  23.  
  24. The Desktop and HyperCard metaphors can interfere with one another.  
  25. This document describes the conditions under which such interference can
  26. occur, and what can be done to avoid it.
  27.  
  28. In the Desktop metaphor users do things by pressing rounded-rectangle
  29. buttons, choosing menu commands, and double-clicking (opening) icons.  
  30. Each type of control object has a distinct, carefully-defined appearance, 
  31. as well as a different method of access.  You can tell how to use a 
  32. control object just by looking at it.
  33.  
  34. In HyperCard, buttons are the principle control objects, but in HyperCard, 
  35. a button can look like anything--an icon, an item in a list, a push button,
  36. a menu item.  Since a click is the only way of starting an action, the 
  37. appearance of a button is less important than in the Desktop: the user knows 
  38. that all HyperCard control objects respond to a single click.
  39.  
  40. When elements of the Desktop and HyperCard metaphors are combined, 
  41. confusion may result.  In an interface with a mixed metaphor, a user 
  42. can no longer predict the result of clicking an item in a list or clicking
  43. on an icon.  Does a click select the object, as in the Desktop metaphor, 
  44. or does it launch an action, as in the HyperCard metaphor?  Clicking on 
  45. an icon to select it and having it launch an action because it's acting like
  46. a HyperCard button is--at the very best--disconcerting.  Such unpredictability 
  47. destroys the comfortable feel that is essential to a good human interface
  48. [Footnote:  Also see Chapter 1 of Human Interface Guidelines: The Apple
  49. Desktop Interface (Addison-Wesley,1987)--in particular, the principles of 
  50. Consistency and Perceived Stability. End Footnote] Users confronted with
  51. such unpredictability are likely to become lost, confused, and unhappy
  52. with your product.
  53.  
  54. Do not mix the Desktop and HyperCard metaphors.  If you're writing a 
  55. HyperCard stack, don't include icon-like buttons that must be double-clicked.  
  56. If you're writing a Desktop application, don't include (to take a real example)
  57. a house icon that takes the user somewhere when it's clicked, like the 
  58. Home Cardbutton in HyperCard. Desktop applications should not contain
  59. HyperCard-like interface elements.
  60.  
  61. The most important point is this:  It should always be obvious whether 
  62. the user is in a Desktop application or a HyperCard stack.  And this means
  63. obvious at a glance; users should not have to read text or remember whether 
  64. an application or a stack was launched.  If the context is obvious, 
  65. the user knows the result of a click--without having to think about it.
  66.